<html>
<body>
<p>DTOs for the remote booking client API.</p>
<!--
<p>
  DTOs are designed in a use case-driven fashion, closely related to the service layer interface.
  They represent a particular section of the domain model, which may cross aggregate boundaries.
  They have no behaviour and are immutable.
</p>
<p>
  The reason for using DTOs is mainly to loosen the coupling of the application and the user interface.
  It allows us to build the domain model completely without having to conforming to any UI-related conventions
  or requirements, such as JavaBean getter methods or no-args constructors. We also avoid exposing functionality that is internal
  to the domain model to the UI layer.
</p>
<p>
  Futhermore, we have a clear contract for what part of the object graph is loaded from the database
  when the service layer call returns. If domain model objects are passed on to the UI layer, it will
  be necessary to keep the database access window (the Hibernate session in this case) open during the entire processing of
  the view (the Open Session In View pattern), otherwise an uninitialized part of the model could
  accidentally be accessed, causing an error. For example, if the UI layer were to receive a Cargo instance,
  that could be navigated to access the Itinerary, iterate over the Legs of the itinerary, access the Leg's CarrierMovement and
  then the CarrierMovement's Location and so on.
  In addition to effectively tying the UI layer and the rest of the aplication to the same JVM,
  letting the UI layer decide when to initialize data may be very inefficient. DTOs are a natural way
  of loading only the relevant data for a particular use case, and blocking access to the rest.
</p>
<p>
  Using DTOs also makes the service layer reusable across different kinds of frontends: web, rich clients, other backend systems etc.
  Remember that classes that are persisted with Hibernate or similar technologies are modified in runtime,
  so that for example collection-valued fields are swapped for customized implementations that allow lazy loading.
  If these persisted domain model classes are to be deserialized in another JVM, those O/R-mapping-specific classes need to be available
  there as well, which is not very elegant.
</p>
<p>
  One caveat though: The usefulness of DTOs may vary with the degree of vertical separation in the application. If it's very
  unlikely that your application will use anything other than a web interface, and that it otherwise are
  no problems running the web layer together with the rest of the application, you may want to avoid the
  overhead of maintaining several similar sets of classes.  
</p>
-->
</body>
</html>